1. Background and Relevant Art
As computer systems have increased in popularity, so have the needs to distribute files and processing resources of computer systems in networks both large and small. In general, computer systems and related devices communicate information over a network for a variety of reasons, for example, to exchange personal electronic messages, sell merchandise, provide account information, and so forth. One will appreciate, however, that as computer systems and their related applications have become increasingly more sophisticated, the challenges associated with sharing data and resources (e.g., a “device,” “application,” or “application component”) on a network have also increased.
One way in which organizations might distribute resources is through the use of tiered applications. With respect to network systems for example, an organization might segment an application into sets of tiered services, where one service of an application at one network location might be configured to perform a specific task, and then communicate the results of that task through network communication protocols with another service of the application at another network location. One reason for distributing an application's services in this manner can be simply to avoid overburdening a particular computer system with a wide range of computing requests for a large number of users, such as might be requested of a web server. For example, an organization might see a computational benefit for isolating some application services at a front-end web server, and isolating other services in the application at more downstream-located services behind the front-end web server.
Additional reasons for distributing an application's services include certain security benefits. For example, the organization might maintain a database of sensitive information through a service at an internal computer system (i.e., a “downstream service”) that is behind a firewall. This is generally understood as the “defense-in-depth principle.” As such, an end-user desiring to access the database data (i.e., at the “downstream service”) will need to initiate a request through the front-end web service (i.e., “upstream service”). If the end-user is appropriately authenticated, the front-end web service of the application might then send a separate, internal request to the downstream database service at the internal computer system. The database service could then return the requested result back to the front-end web service, which then delivers the information to the end-user. Such a configuration can thus provide an end-user with access to certain internal information, while also guarding to some extent direct access to the an application's various levels of downstream services at internal computer system(s).
To reap the security benefits mentioned above, however, an organization will generally need to address additional considerations, such as how to limit the execution of mission critical code at downstream services to a set of trusted identities. In addition, the organization might be concerned with how to enable downstream services to make access control decisions based on the identity of the end-user making the application service requests. These and other similar considerations might be further complicated by regulations that mandate that businesses keep on audit trail of all data related activities, regarding who accessed what data and when.
Some organizations attempt to solve these difficulties by configuring downstream services to operate in accordance with trust levels for properly authenticated end-users. In particular, downstream services might be configured to trust process requests relayed by upstream services (e.g., the front-end web service) only if the upstream services are “impersonating” a properly authenticated end-user. For example, a front-end web service might receive an outside end-user request that includes some end-user authentication information (e.g., user name and password). The front-end web service might then relay the request to an internal application service at an internal computer system on behalf of the end-user, such as by providing the end-user's supplied user name (e.g., using Kerberos mechanisms). The downstream service might, in turn, be configured to only accept and process the request from the upstream service if the downstream service can also authenticate the supplied user name.
However, impersonation-based configurations also introduce the issue of process privilege elevation, which can result in more damages in the event of security compromises. Furthermore, some impersonation-delegation systems may require the upstream service to obtain a service ticket on behalf of the outside end-user from a security authority before allowing the upstream service to access and/or invoke downstream services. Such security negotiation with a security authority can introduce extra communication latency, particularly for application services that may be acting on behalf of a large number of users. Unfortunately, simply caching security contexts across multiple outside requests can violate stateless recommendations for high performance application services.
This difficulty can extend into additional implementations otherwise thought of as network optimizations. For example, some application services may be configured to share a pool of preset communication channels for connecting and communicating with downstream services. In particular, an organization might desire for some business logic-tier services to pool database connections to a downstream database in order to optimize performance. With impersonated connections, however, the downstream database may be required to authenticate each connection, which thus undermines the potential optimizations of pooling.
Furthermore, a couple of additional problems can flow from configurations where downstream services are secured only with a specified user's identity. At the outset, for example, such a configuration can provide end-users with the ability to invoke business logic services, which can also increase the complexity of managing access control for a particular service. In addition, such a configuration may allow any type of application service in the system to make an impersonation, and thus potentially allow any upstream service to call mission-critical code. Such a configuration, therefore, violates a particular view of the defense-in-depth principle, which suggests that there should be a gradual reduction of the number of identities that can access higher value assets (e.g., those managed by downstream services). In particular, the defense-in-depth principle suggests that inner business logic services should be restricted to a gradually smaller set of application identities in the downstream direction.
Accordingly, there are a number of difficulties associated with securing multi-tiered application communications.